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This project aims to build a data analysis system that will 
utilize existing video tape scenes of lightning as viewed from 
space. The resultant data will be used for the design and 
development of the Lightning Imaging Sensor (LIS) software and 
algorithm analysis. The desire for statistically significant 
metrics implies that a large data set needs to be analyzed. 

Before 1990 the quality and quantity of video was insufficient to 
build a usable data set. At this point in time, there is usable 
data from missions STS-34, STS-32, STS-31, STS-41, STS-37 and 
STS-39. During the Summer of 1990 a manual analysis system was 
developed to demonstrate that the video analysis is feasible and 
to identify techniques to deduce information that was not 
directly available. Because the closed circuit television system 
used on the space shuttle was intended for documentary TV, the 
current value of the camera focal length and pointing 
orientation, which are needed for photoanalysis, are not included 
in the system data. A large effort was needed to discover 
ancillary data sources as well as develop indirect methods to 
estimate the necessary parameters. 

Any data system coping with full motion video faces an 
enormous bottleneck produced by the large data production rate 
and the need to move and store the digitized images. The manual 
system bypassed the video digitizing bottleneck by using a 
genlock to superimpose pixel coordinates on full motion video. 
Because the data set had to be obtained point by point by a human 
operating a computer mouse, the data output rate was small. The 
loan and subsequent acquisition of a Abekas digital frame store 
with a real time digitizer moved the bottleneck from data 
acquisition to a problem of data transfer and storage. The 
semi-automated analysis procedure was developed using existing 
equipment and is described below. A fully automated system can 
be described in the hope that the components may come on the 
market at reasonable prices in the next few years. The fully 
automated system would control an external videocassette recorder 
by reading a time code on the tape then capturing a sequence of 
frames, transfer the digitized images to the computer memory and 
then extract the lightning data using the LISO algorithm. If the 
system were fully automated, it would rewind the video tape and 
capture the next section of data until several minutes of data 
were processed. The ideal system would also capture data encoded 
in the vertical blanking interval of the original video, decode 
these pixels to determine GMT and camera motion. The ideal system 
would also have sufficient multitasking capacity to update the 
orbiter position on a second by second basis. 

Semi-automated Analysis Procedure 

Several aspects of video analysis need to be addressed. 

Video data is produced rapidly. Thirty frames are recorded in a 
second but a low cost digitizer may need five seconds to digitize 
a single frame and it would consume the better part of a minute 
to label the file, store the data and use the mouse to get pixel 
location data at several features in the image. Each second of 
data produces about 10 Megabytes of monochrome digitized image 
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data and could take about a half hour to digitize. A "real time 
digitizer" (1/30 second for a frame) speeds up the digitizing 
work but aggravates the data storage problem. One way to avoid 
the data storage problem is to superimpose a crosshair on the 
video and read data points without ever digitizing the images. 
That was the idea behind the manual analysis method. The 
automated method digitizes every frame in a sequence then 
discards pixel information not related to lightning. A typical 
video sequence would be of the order of one hundred seconds in 
length. The digitized images files for one hundred seconds would 
contain about 1 gigabyt e of data which w ould exc eed the 
throughput of existing equipm ent. .. One hundred se co nds of data 
would have to be captured as many shorter sequences. If one 
manually started and stopped the VCR some overlap of the start 
and end of the short sequences would be necessary to be certain 
there were no gaps in the digitized records. This would produce a 
large volume of duplicate data that would hav e to be sorted and 
discarded. 

The semi-automated analysis procedure starts by linking a 
Sony 3/4 inch tape recorder to the Abekas input and connecting 
the channel 2 audio (SMPTE code) output to the input of a SMPTE 
time code generator to regenerate a control signal to start the 
frame capture sequence. In order to record frames with accurate 
start and stop frames, the SMPTE code for the start frame must be 
ente red into the ABE KAS as. well as the n umber of frames to' 
capture. After the tape is started, the time code generator is 
reset in order to slave the generator to the video source. The 
Abekas digital frame store will automatically capture several 
hundred frames. The starting frame for the next segment would be 
hand calculated and the recording process repeated until the 
entire video scene was captured. It is necessary to move the 
data from the Abekas via ethernet to a computer to proceed with 
the analysis. Paul Meyer has written a utility LI SGRAB that moves 
a sequence of image files over ethernet and stores them on the 
Stardent in sequentially labeled files. 

Level 0 data will be raw instrument data at original 
resolution, time ordered, with duplicates removed. This data 
will be downlinked from the LIS instrument. The LIS00 algorithm 
produces lightning data by extracting illuminated video pixels 
from a background as it scans a sequence of data files. This 
code reads one image file at a time and builds a background 
buffer that is the average of the last four valid background 
intensities for each pixel of interest. Data which exceed 
background and a threshold are not added to background but are 
sent to the output. The LIS00 output stream consists of the file 
ID (based on the GMT) , video pixel X, Y and amplitude. Test 
cases will be used to determine the ability of simple, quick 
algorithms to separate lightning from nighttime background 
lights. Examples of interference include video noise introduced 
at the camera focal plane, the video downlink, the copying and 
digitizing process as well as aircraft beacons and explosions. 
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The output of LISOO is sent to LISO which uses pan, tilt, 
altitude and focal length information to map the original oblique 
view video pixels into a nadir view with 10 km resolution. 

Because the higher resolution video data will map several pixels 
into the same 10 km resolution pixel the data will be sorted to 
remove duplicates. The output of LISO is a data stream 
consisting of time, pixel location and amplitude. This data is 
called imitation LIS level 0 data because the video data is at 
lower time resolution than the LIS level 0 data and the video 
oblique view produces data that would be out of view of the real 
LIS. 


The LISO algorithm also removes duplicates by retaining the 
maximum value for a particular LIS pixel. Present LIS plans call 
for downlinking the background scene at fixed intervals. The 
background scene will be examined to verify the location and 
orientation of the platform as well as pixel calibration. 
Decisions are needed concerning the frequency of the background 
transmission, the source of this data (real time or averaged 
background) , and whether to report this as part of LIS 0 data or 
store locally and discard. The background scene will be helpful 
in identifying optical events that are not produced by lightning. 
Optical pulses from cloud-free areas near cities can be discarded 
because they are generated by human activity. 

LIS Level 1 data consist of the level 0 data stream packed 
with geo— ref erencing information and ancillary data. This data 
product will also contain a time stamp computation and 
calibration information. The LIS1 algorithm combines two data 
streams: the LIS 0 data stream and reference data from the 
platform. At present the content and format of the platform data 
has not been determined. Simulated time and location data will 
be generated to provide a data stream. Since LIS data will be 
asynchronous with respect to the orbital motion a decision is 
needed on whether to report platform data when there is no LIS 
data. 


Level 1A data products are transformed values of full 
resolution instrument measurements. The data stream will consist 
of individual optical pulses with Universal time of origin, 
Latitude and Longitude of source, radiance of pulse and threshold 
setting. This data stream provides the most detailed set of 
calibrated data. Decisions are needed on the format of the 
output product. 

Level 2 data consist of geophysical parameters located in 
time and space. The items of interest here are lightning stroke 
and flash identification. Optically, a single lightning flash is 
comprised of a series of discrete short duration optical pulses 
associated with energetic discharge processes occurring within a 
cloud. The individual optical pulses will be grouped to provide 
a single location (initial location) and starting time for a 
stroke. If another stroke is found in close time and spatial 
proximity, the combined event will be classed as a multistroke 
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lightning flash. Other luminous events such as meteors, sun 
glint, explosions, strobe lights and search lights may have to be 
identified at this stage. It must be noted that not all optical 
events in a flash will exceed the LIS < threshold and be detected. 
The most important derived parameter is the lightning flash 
rate. The platform will be in a polar orbit which limits the 
time of continuous observation of any point within the field of 
view to about two minutes. This implies that strokes occurring 
at a particular location must be averaged for an observation 
period. Decisions are needed about which location to report for 
a lightning flash that extends over several pixel locations. 

Since the flash extends oyer time a second decision is needed 
regarding the choice of time tag. 

The primary task of the level 2 algorithm is to group 
optical pulses into strokes, group strokes into flashes and count 
flashes at a location. It is desirable to perform the initial 
grouping as the time sequential data st ream arrives. After a 
particular location has passed out of view and the incoming data 
stream will no longer contain relevant data, then the final 
summary of the data for a particular location can be 
constructed. A preliminary look at the algorithm suggests that 
the classification could be done on the level 0 data stream using 
coordinates relative to the LIS instrument. After the optical 
pulses are grouped, the location and start time of a grouping 
could be computed using platform data. With the flashes 
identified, the level 1A data could be organized on a flash by 
flash basis rather than a time of arrival basis. This algorithm 
would be more efficient because the level 1A data stream is 
larger than the level 0 data. 

Level 3 data products consist of LIS geophysical parameters 
mapped and time averaged onto a uniform Earth based grid. 

Standard level 3 products will be produced with spatial 
resolution between 0.1 degree and 2.5 degrees. The data will be 
accumulated to produce global pentads, monthly, seasonal, yearly, 
annual and interannual maps of lightning. LIS level 3 products 
will include maps and statistics of total optical pulses, total 
flashes, flash densities, radiant intensities, discharge type and 
flash duration as well as mean and extreme value statistics. 

Since these mapping and statistical function are common to most 
EOS instruments, the EOSDIS contractor is expected to produce a 
tool kit for consistent mapping and statistical treatment of many 
different data sets. The run time of these tools may be improved 
by producing the LIS level 1A data grouped by flash. The polar 
orbit provides for extensive overlap of the viewing area during 
successive passes of polar locations. Since the observing time 
enters into the statistical significance of the data the EOS 
contractor is expected to address this need for all instruments. 
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